Glad you came back for more rib-groups fun!
We are now going to take a look at some applications of rib-groups that you might find interesting and applicable to your real networks.
Warning: Brace for some extra topics!
CASE 1 – Filter Based Forwarding – FBF
Let’s say that your network consists of two sites connected through two different ISPs, as shown in the picture.
You have video, voice and data traffic, but because of the nature of your business, you are mainly concerned with making sure the voice and video gets the best Service Level possible, even if you have to pay more.
To achieve this, you want your routers to forward voice and video traffic over ISP A, while the data traffic is forwarded over ISP B.
Why would I want to send voice and video over ISP A and data over ISP B you might ask?
Well, let’s say you have determined that ISP A provides the best SLA and meets all the requirements of your voice and video. ISP B, on the other hand, provides a more basic service, with the benefit of being way cheaper, so you can save money and spend it on your important traffic.
The question now is: how do we make sure that the traffic is actually sent to the correct ISP based on the type of traffic?
NOTE: To answer this question, we are going to focus on R1 sending traffic to R2, but you will want to do the same on R2, so that you get the same behavior in both directions.
Let’s see! As you know, routers make forwarding decisions based on the destination address of the packet.
In our network, whenever traffic from a device in SITE 1 is destined to a device in SITE 2, a layer 3 lookup is performed based purely on the destination address of the packet. The router is looking for the best match between the destination address and the entries in the routing table. The kind of traffic is irrelevant when searching for this route.
Also remember that in Juniper devices, there is a routing table built by the Routing Engine, and a forwarding table (at the Packet Forwarding Engine) that contains the best routes to each destination based on metrics, preference and policies.
The Routing Engine makes this selection, build the forwarding table and passes it to the PFE. When packets arrive forwarding decisions are made using information in the forwarding table.
If your router (R1) is not configured to perform load balancing, which is the default in Junos, it will have two next hops in the routing table, pointing to ISPs A and B, but only one next-hop will be placed in the forwarding table.
As a result, your router might end up sending ALL traffic to ISP A, which is NOT good!
Your data traffic is getting VIP service, while possibly degrading your video and voice traffic, and likely making you pay more!
The router might actually end up sending ALL traffic to ISP B which is even worse!
If you decided to enable load balancing at this point, things would get really bad actually !!
Hashing of SA, DA, protocols, and port numbers would determine which link will be used for each flow (conversation or data exchange), and your voice, video, and data traffic would being load shared across the two links with no discrimination.
You need your routers to be able to distinguish between voice, video, and data traffic and act accordingly. In other words, you need your routers to do some form of traffic classification that will determine how the traffic is to be forwarded.
Good news! We can easily accomplish that by creating and applying a firewall filter that looks into the source and destination addresses, protocols, and port numbers and separates voice and video traffic from data traffic.
The action of this firewall filter will make the router bypass the normal routing processing, so that traffic is forwarded as desired.
This filter will say: “for this traffic, don’t go to inet.0 to find a route, go to VR1.inet.0 (for example) instead.”
Let’s apply this idea to our scenario.
We are first going to configure two routing instances: VRA and VRB, which will create two separate routing tables VRA.inet.0 and VRB.inet.0 (and their corresponding forwarding tables).
VRA.inet.0 will be used to send traffic to ISP A, and VRB.inet.0 will be used to send traffic to ISP B.
On each of this routing tables we can add a static route to reach the prefix in SITE 2, 172.20.2/24.
Or we can simply add a default route.
Then, we configure the firewall filter, and apply it inbound to the interface where our end users are located.
The filter would look something like this:
The first term in the filter matches on destination-address 172.20.2/24 (SITE 2), and the protocols and port numbers of RTP and H.323. The action for traffic that matches all the criteria is “then routing-instance VRA”, which will cause the router to perform a route lookup in VRA.inet.0, which has a static route pointing to ISPA.
All other traffic going to 172.20.2/24 will match term 2, and the action will be “then routing-instance VRB”, which will caused the router to perform a route lookup in the VRB.inet.0 which has a static route pointing to ISPB.
The final term accepts any other traffic. This traffic could be going to the internet for example, which you might want to be routed based on the routes in inet.0.
“OK great! But wasn’t this article about rib-groups? Where are the rib-groups?” 😊
Well, let’s go back to the static routes we configured within the routing instances:
We created the routing-instances and configured the static routes by entering:
Notice that:
1) The instance-type is forwarding. It is NOT a virtual-router!!
This type of routing-instance is much simpler. It does not require, or even accept configuring interfaces or routing-protocols, and only allows the configuration of static routes.
Their purpose in life: to create a separate forwarding table that you can use to forward traffic a certain way. Use case: Filter Base Forwarding! 😊
NOTE: don’t forget to add the instance-type.
The default routing-instance type is no-forwarding!!!!! This type of routing instance allows configuring interfaces (except for lo0), and protocols with some restrictions, but it has no corresponding forwarding table. Not very helpful for our use case!
2) We did NOT configure any interfaces under the routing instances:
And that means: NO interface routes!!! No local routes! No Direct routes!
If you have read my article about manually configured routes, you will remember that static routes are not valid if the next-hop is NOT reachable, within the routing table the static route will be installed on.
Thus, when you configure this:
The static route will NOT be installed because the next-hop 10.1.1.2 is NOT reachable within VRA.inet.0.
Then, why not just make this routing-instances virtual routers, and add the interfaces ge-0/0/3 and ge-0/0/4 to them respectively, and be done ?
That is an option, but in our scenario it would work well if we assumed that our users in SITE 1 and SITE 2 ONLY need to talk and exchange data among themselves. How likely is that? ZERO!! They probably also want to have the ability to connect to the internet.
We could for example, have a default route advertised to us from the ISPs. These routes would be installed in inet.0. We can change the local preference so that the default route from ISP B is preferred, and then we can apply some policers, or firewall filters to the interface going to ISP A so that in the case of a failure connecting to ISP B only some of the internet bound traffic, and up to a certain rate, is allowed towards ISP A.
Bottom line is:
I don’t want to make interface ge-0/0/3 and ge-0/0/4 part of any routing-instance! I need then to stay in inet.0.
Then, how do we make our static routes work?
You bet! Let’s use a rib-group to install the interface routes for ge-0/0/3 and ge-0/0/4 in both inet.0 and the respective routing instance’s table.
Once the rib-group is applied, we will have the necessary routes in our routing instances’ tables to forward the traffic:
To show you how the traffic is now following the required path, I configured a couple of simple firewall filters to count and log packets out of ge-0/0/3 and ge-0/0/4, and added some counters to the FBF filter:
I am also simulating an end user in network 172.20.1/24 with a routing instance named SITE1_VR within R1:
Initially all counters are clear.
We try to connect to a remote device in SITE-2 on port 1720:
The counters to-VRA and count3 are incremented. This shows that packets are matching term 1 of firewall filter FBF, are being sent to routing-instance VRA, and out out of ge-0/0/3.
We also try to connect to a remote device in SITE-2 on port 16382:
And again, we see the counters to-VRA and count3 are incremented. This shows that packets are matching term 1 of firewall filter FBF, are being sent to routing-instance VRA, and out of ge-0/0/3.
We then try to connect to a remote device in SITE-2 on port 23
And this time, we see that the counters to-VRB and count4 incrementing. This shows that packets are matching term 2 of firewall filter FBF, are being sent to routing instance VRB, and then out of ge-0/0/4.
As a last test, we try to access a device over the internet:
And we see the to-inet.0 counter within firewall filter FBF and the counter applied to interface ge-0/0/4 incrementing.
Note: there is a static default route pointing towards ISPB installed in inet.0 for this test.
Summarizing the steps:
1) Create a firewall filter and apply it to the input interface:
This filter will classify traffic and send it to the appropriate routing instance for processing.
2) Create the routing instances and add the static routes:
Each routing instance creates a separate routing table, and associated forwarding table, to forward traffic across the desired path.
3) Create and apply a RIB group
Installs direct routes in the routing instances routing tables, to allow next-hop resolution for the static routes.
4) Verify route installation.
We can see that the direct route for interfaces ge-0/0/3.0 and ge-0/0/4.0 direct route, and that the static routes we configured are installed and active.
5) Test path followed by traffic.
CASE 2 -MULTICAST RPF TABLE
Let’s say now that we want to exchange unicast and multicast traffic as shown in the picture:
The routers are learning about 172.20.1/24 and 172.20.2./24 from BGP, and are choosing the routes from their neighbors in NetworkB as the best routes to reach 172.20.2/24 from R1, and 172.20.1/24 from R2.
Thus both routers are seeing the route via their ge-0/0/4.0 interface as the best route. (There is actually an import policy that changes the local preference so that these neighbors are preferred).
We don’t need to worry about unicast traffic, which is following the desired path. But when we check which path the multicast traffic is taking, we discover that is following the exact same path as the unicast traffic.
Let’s see why.
NOTE: For simplification, let’s assume we are doing PIM dense mode.
The server 172.20.1.1 stars sending the multicast traffic. R1 receives it and floods it out of ge-0/0/3.0 and ge-0/0/4.0.
The traffic is flooded across Networks A and B, and is received by R2 on both interfaces ge-0/0/3.0 and ge-0/0/4.0
When each multicast packet arrives, R2 performs RPF (Reverse Path Forwarding) checks, to determine if the packet should be forwarded or not.
What is RPF?
RPF verifies that traffic is being received on the best interface back to the source. That’s right! back to the SOURCE!!!
When the packet arrives the router does a route lookup and finds the best route to the source address.
- If the packet arrives on the same interface as the outbound interface of the best route to the source, the packet passes RPF.
- If the packet arrives on an interface that is not the same as the outbound interface of the best route to the source, the packet fails RPF.
Routers perform RPF checks for multicast traffic which causes the multicast traffic to be pushed away from the source (the multicast server), and hopefully closer to the receivers. The main purpose is to avoid loops by never sending the traffic back to the server (the source), even though we are flooding it out.
In our scenario, when R2 receives a multicast packet on interface ge-0/0/4.0 it checks the routing table.
As we saw before, the routing table shows that the best route to get to 172.20.1/24 is out of interface ge-0/0/4.0.
Thus, because the packet arrived on this interface, it passes RPF and is forwarded.
R2 also receives a multicast packet from the same source on interface ge-0/0/3.0.
Following the same process, the router determines that this packet did not arrive on the correct interface, and therefore it should be discarded.
If you think about it, not discarding it would mean flooding it out of all interfaces again, including ge-0/0/4.0, which would send the packet towards the source, causing a loop.
Now, the router not just drops the packet, but it also sends a prune message out of interface ge-0/0/3.0(*) which tells the router upstream to stop sending the traffic.
(*) Assuming the interface p2p – for a broadcast interface there is some other steps involved but we are not covering that here. In all cases traffic is no longer sent by the upstream router, on that interface, until the reflooding timer expires.
As a results of the RPF checks, which cause the router to discard the traffic that fails, and to prune the interface, the multicast traffic ends up forwarded along the same path as the unicast traffic
Right now in our example network, the routes used for RPF checks for traffic coming from sources in the 172.20.1/24 and 172.20.2/24 are the BGP routes that point out of ge-0/0/4.0.
You can see that by entering the following command:
Hopefully, one very important detail on the last two show command outputs caught your attention:
RPF checks for multicast traffic are performed using information in the unicast routing table, and by default that means: inet.0!!!
Yes, let me say that again: multicast RPF checks are done using inet.0 by default!
I have been asked a few times: “but what about inet.1 or inet.2? I thought those were the tables used to forward multicast traffic”.
Well, inet.1 is the IPv4 multicast forwarding cache and it stores IPv4 (S,G) group. Basically a list of multicast source and group pairs (S.G) entries like this:
The detail version of the command would show a reference to the next-hop or outgoing interface(s).
inet.2 is a different story. Surprisingly, it is NOT a multicast routing table. It is actually a UNICAST routing table, and it can be used for RPF checks for multicast traffic. Though, as we just learned, it is NOT used by default.
Going back to our original dilemma:
We want multicast traffic to be sent over the ge-0/0/3 interface but RPF is not letting us! It is causing the ge-0/0/4 interface to be used instead.
So the key here is: we need to tell RPF that ge-0/0/3 is better than ge-0/0/4!
Since we are using BGP in order to make ge-0/0/3 better that ge-0/0/4 we would need to modify the local preference. But we don’t want to do that across the board. We want to change it only for the purposes of RPF checks and we don’t want to affect unicast traffic also!
That basically translates into: we cannot touch inet.0, which brings us to:
We need a different routing table for RPF checks!!! Yes! inet.2 to the rescue.
Changing the RPF routing table:
First, we need to tell RPF to use inet.2 instead of inet.0, and for that, guess what we will need.
We create a very simple rib-group that only has inet.2 as the routing-table to import routes in:
And the apply the rib-group to PIM:
Remember, this is telling PIM to do RPF checks using “rib-group mcast-rpf-rib”, which means inet.2, instead of inet.0.
Once we apply the changes, we issue the show multicast rpf command again and confirm that rpf will now use inet.2:
After we reconfigure RPF to use inet.2 we need to make sure we have proper routing information.
At this point, we check the contents of inet.2 and discover that the table is empty!
Thus, our next step will be to add routes to inet.2
Since we are running BGP we can add family multicast to our sessions so that BGP routes are installed in inet.2.
By the way, here is a common misconception. Adding BGP family inet multicast does not mean BGP will advertise multicast routes.
Adding BGP family inet multicast means that the BGP routes received will be installed in inet.2, and that the routes advertised will come from inet.2
NOTE: don’t forget to add family inet unicast. When you explicitly configure any address family under BGP, the router stops advertising IPv4 unicast routes, which is what is advertised by default.
After making the changes on all the routers, we check the status of our BGP neighbor sessions
And we find that the sessions are now advertising routes to be installed in inet.0 and inet.2.
We can also use show bgp neighbor, and see how both the unicast and multicast address families were negotiated.
However, we noticed that we still have no routes in inet.2, and that R1 and R2, are not advertising anything for family inet multicast:
The reason? Again! inet.2 is empty! No direct routes, no local routes!
The export policy that we are applying matches on 172.20.1/24:
For family unicast, there is a direct route for this network in inet.0, but there is no route in inet.2
Let’s fix that with a rib-group:
inet.2 now has routes for 172.20.1/24, and routes for unicast and multicast are being advertised:
We are still not finished though.
The routers are still preferring the routes via ge-0/0/4.0 for both unicast and multicast.
We will need to modify our policy to change this.
Now, unicast traffic will be forwarded out of ge-0/0/4 and PIM RPF checks will be successful when multicast packets arrived at interface ge-0/0/3! Just as we wanted.
Summarizing the steps:
1) Create a rib-group that only has inet.2 as the routing-table to import routes in:
2) Apply the rib-group to PIM:
This will tell PIM not to use inet.0 for RPF checks bu the routing table defined under rib-group mcast-rpf-rib (inet.2)
3) Configure BGP to advertise family inet multicast
This will tell BGP to import and export UNICAST routes to and from inet.2.
Because we are also adding family inet.0, BGP will also import and export routes to and from inet.0
4) Configure a policy that redistributes the connected interface into BGP
This will advertise the customer SITE’s prefix.
5) Configure another rib-group to install interface routes in inet.2
This will add interface routes to inet.2 so that next-hop resolution is possible, and so that BGP can find routes in inet.2 to advertise to the remote peer.
6) Verify that RPF checks are now performed using routes from inet.2
7) Verify that we now have different routes in inet.0 and inet.2 as required.
CASE 3 – Internet Access to VPN customer.
The Service Provider in this example has a customer with two sites connected using an L3VPN.
The customer also wants internet access for the two sites, which will be provided across the connection to the Service Provider on SITE 1.
NAT will be implemented by the customer for Internet bound traffic using the address of the interface between the CE and PE routers.
Let’s take a closer look at the connection between the CE and PE router in SITE1 to understand what we are trying to achieve when configuring the PE routers:
Between CE1 and PE1 there is an EBGP sessions that terminates within a VRF routing instance. The customer will advertise the internal prefix 172.20.1/24 and will receive the internal prefix from SITE 2, and also a default route.
Here is the configuration of CE1 and PE1 for this BGP session:
There is an equivalent configuration between CE2 and PE2 (not included here) .
Let’s check that the CE-PE sessions are established, and the CE routers are advertising the sites internal prefixes.
PE1 will also have an IBGP session with PE2 (remote PE connected to SITE 2). This IBGP session will be established between the loopback interfaces of PE1 and PE2, which will be advertised inside the service provider’s autonomous system (AS200) using ISIS. The ISIS routes to reach the remote PE loopback interface will be installed in inet.0
The PE routers will exchange L3VPN routes (family inet-vpn) advertising the SITEs internal prefixes 172.20.1/24 and 172.20.2/24, and also the direct routes of the links CE to PE.
These routes will have the route distinguisher and a route-target BGP community that we configured under the routing instance, and a VPN MPLS label.
Let’s take a look at the routes that PE1 is advertising to PE2:
The VPN Label will be used to tag traffic so the receiving PE router knows which VRF the traffic belongs to.
The route-target community value will be used by the receiving PE router to determine which routing table the routes should be installed in.
Because these routes are L3VPN routes, even though the IBGP session advertising them is established using information in inet.0, the routes will be installed in the VRF’s routing table (VRF.inet.0) with matching route-target .
We can see that PE1 and PE2 are exchanging L3VPN routes, for the customer’s SITE prefixes:
Notice that the routes include an LSP (Label Switched Path) as part of the next-hop. This means that on top of the VPN label we saw before, there will be another label to reach the remote PE, across the Service Provider’s MPLS network. These LSPs are required for the L3VPN routes to be usable.
These MPLS LSPs are also terminating in the loopback interface (the same loopback address used for the BGP session!)
When these LSPs are established, routes to the egress node address are installed in a routing table called inet.3, which can only be used by BGP for next-hop resolution (by default).
The BGP next-hop for the L3VPN routes exchanged between the PE routers, is the address they are peering with (their loopback interface addresses).
When these routes are received, BGP has to perform next-hop resolution using inet.3, because labels are required to forward the L3VPN traffic across the network.
As a result, when the routes are installed in the corresponding VRF.inet.0 they will have the LSP as next-hop as shown in the output of the show route command above.
Now, here you can see that for the routes received by PE1 the next-hop is the loopback of PE2 10.100.100.6.
For next-hop resolution of an l3vpn route BGP must find the next-hop in inet.3:
This route was installed by RSVP after the LSP PE1-to-PE2 came up. BGP uses this route to resolve the next-hop and the result is installed in the VRF’s routing table:
I know! I know! where are the rib-groups? They are coming!
So far, we know:
- Routes received from the CE routers are installed in the VRF’s routing table because the interface connected to the CE, and the BGP session with the CE are configured within the VRF.
- Routes received from the remote PE are installed in the VRF’s routing table, because they have a matching routing target.
- On the CE routers, the routes go to inet.0.
At this point, all the L3VPN pieces all ready to carry traffic all the way from SITE-1 to SITE-2:
And we can even test that traffic is going through:
Easy! But no comes the challenging part. Internet Access!
Outbound internet traffic
First thing we need to take care of is the default route that the customer needs, to be able to send traffic to the internet.
This route has to be advertised across the BGP session CE-PE. In other words, the BGP session configured under the VRF.
So, we configure and apply a policy.
But still no default route is being advertised:
That actually has a good explanation:
The export policy says: “go to the routing table, find a route that matches 0/0 exact, and then advertise it!”
Well, there is no default route in the VRF’s routing table. Let’s create one.
So, here is out new dilemma:
The CE routers will be sending internet bound traffic to the PE routers, which will need to perform a route lookup in the VRF’s routing table, as traffic will be arriving on the interface connected to the VRF.
The route in the VRF has to send traffic towards the internet, meaning, out of interface ge-0/0/2.0 but we know what will happened if we just configure the static route with a next-hop of 10.100.13.2 right?
Repeat after me: “static routes are not valid if the next-hop is NOT reachable, within the routing table the static route will be installed on.”
Our static default route will not be installed because the next-hop 10.100.13.2 is NOT reachable within VRF.inet.0.
But hey! Aren’t you excited? You now know how to fix this!!!!!
Here we go:
And here is our default route in the VRF’s routing table:
The default route is now being advertised to the remote PE router:
And, the remote CE router now has a default route as well.
CE1 however, is not yet receiving the default route.
That is because the route is static and by default we don’t export static routes into BGP. But we just need to add an export policy to the BGP session under the VRF:
And now we are all set for outbound traffic:
And by the way, some of you might be wondering: why we didn’t need to do the same to advertise the static default route via BGP to the remote PE?
The answer might surprise you! We do need a policy that redistributes non-BGP routes in the VRF into BGP, to send the routes to the remote PE! Only that this is done automatically for us, when we configure vrf-target under the VRF.
You might know that when you create a VRF there are 3 options to configure the route-target community:
When you use the first two options, the corresponding policies are created automatically. You can see them with show route instance <vrf-name> extensive.
In our lab we configured the routing instance with vrf-target target:200:1. This is the result:
OK, back to our scenario: We got the default routes installed in both CE routers, and we have a default route on the VRF.inet.0 of PE1 pointing out of the internet interface. That takes care of the internet outbound traffic. But what about return traffic?
Inbound internet traffic
When traffic arrives from the internet on interface ge-0/0/2, the router will do a route lookup in inet.0, since interface ge-0/0/2 belong to inet.0 (it is not configured under any routing instance).
Traffic from the internet destined to the customer will have a destination address from the 198.51.100/24 range. We don’t have any routes for 198.51.100.X in inet.0 at this time.
We can use another rib-group and share the routes also, but the easiest way would be this: Create a static route in inet.0 that sends the packet for a second lookup in the VRF’s routing table using next-table.
We also need to make sure the PE router advertises the customer’s prefix so routers over the internet can send traffic back.
PE1 is peering with the gateway router out of interface ge-0/0/2.0. We will add the customer prefix to the policy that advertises routes to this gateway:
And now our customer is able to send SITE to SITE traffic as well as SITE to Internet traffic:
Summarizing the steps:
Outbound Internet traffic from customer sites:
1) Create a default route in the VRF routing table of PE1 pointing to the internet gateway 10.100.13.2
2) Create a rib-group and policy so that the direct route for interface ge-0/0/2 connecting PE1 to the GW, is installed in both inet.0 and VRF.inet.0.
3) Add policy to advertise the default route to CE1:
Remember that the route is automatically advertised to the remote PE and CE.
Result:
- When users at CE1 and CE2 send traffic to the internet, their source address will be natted (Customer’s responsibility) into addresses out of the 198.51.100/24 address range.
- The CE routers will send traffic to their local PE routers. PE2 will send the traffic to PE1 across the VPN.
- On PE1 internet bound traffic will match the default route that points out of interface ge-0/0/2 and towards the internet gateway.
Inbound Internet traffic towards customer sites:
1) Create a static route for 198.51.100/24 pointing to the VRF’s routing table:
2) Configure a policy that advertises the customer VPN routes from PE1 to the GW:
3) Verify route is being sent to gateway:
4) Verify customer can access the internet
Result:
- When traffic comes back from the internet it is sent to PE1 across the ge-0/0/2 link.
- PE1 receives the traffic and because ge-0/0/2 belongs to the master routing instance, it performs a layer 3 lookup in inet.0.
- inet.0 has a route that causes a route lookup over VRF.inet.0, which has the routes to the customer’s specific prefixes 198.51.100/30 and 198.51.100.4/30
THE NEXT-TABLE OPTION:
One last thing before we close the topic:
Now that you’ve seen the beauty of the next-table option I am sure some of you will say: “we should have done next-table for outbound traffic also, and forget about rib-groups!!! “
Nice try!!! But, guess what, Junos will NOT let us!
To prevent us from shooting ourselves in the foot, causing loops between routing tables that I imagine could get worse than a L2 loop, we can use the next-table option only in one direction.
You can do this:
Or this:
But most definitively NOT this:
And with that, we have concluded our newest edition of momcanfixanything!
Recent Comments